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REMARKS/ARGUMENTS 
Claims 1-31 are cancelled. Claims 32-62 are new. Claims 32-62 are pending in the 
application. The amendments to the claims as indicated herein do not add any new matter to 
this application. Furthermore, amendments made to the claims as indicated herein have been 
made to exclusively improve readability and clarity of the claims and not for the purpose of 
overcoming alleged prior art. 

I. ISSUES NOT RELATED TO PRIOR ART 

The Office Action requested that page 1 of the Specification to include the serial 
number of the related application. Applicants filed a Preliminary Amendment on April 16, 
2004 amending the reference to the related application to include the serial number. 

Claims 32, 37, 44, 51, 58, and 60 were objected to for various informalities. Each issue 
raised with respect to these informalities has been addressed. 

Claims 51-57 stand rejected under 35 U.S.C. § 101 as allegedly being directed to non- 
statutory subject matter. As instructed in the Office Action, Claim 51 has been amended to 
recite U A computer-readable medium, tangibly embodied on a physical storage medium, 
carrying one or more sequences. ..." Each of the dependent computer-readable medium claims, 
by virtue of their dependency, recites the "tangibly embodied" language. Therefore, removal of 
the 35 U.S.C. § 101 rejection with respect to Claims 51-57 is respectfully requested. 

H. ISSUES RELATING TO CITED PRIOR ART— BROMAN, THURSTON, 
BRODKORB 

Claims 32-62 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over U.S. 
Patent No. 36,754,858 to Broman et al. ("Broman") in view of U.S. Patent Application 
Publication No. 2003/0217193 Al to Thurston et al. ("Thurston"), and further in view of U.S. 
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Patent Application Publication No. 2004/0133875 Al to Brodkorb et al. ("Brodkorb"). This 
rejection is respectfully traversed. 

The Office Action originally cited U.S. Patent Publication No. 2004/0133875 Al to 
Kramer et al. ("Kramer") instead of Brodkorb when rejecting all the claims. However, the 
Office Action only applies portions of Brodkorb to claim 32 (Office Action, page 6) and does 
not refer to Kramer in the rest of the Office Action. Therefore, this reply only addresses 
Brodkorb) 

A. CLAIM 32 
Present Claim 32 recites: 

A method of a development and build environment for packaged software delivery in 
a distributed network of nodes, the method comprising the computer-implemented 
steps of: 

compiling source code files into executable file modules; 
wherein each of one or more modules contains an image for a process or a 
dynamically linked library (DLL); 

creating a software package that comprises the one or more modules, wherein the 
software package is delivered to the nodes in the distributed network; 

wherein the software package is created based on at least one of a feature, characteristic, 
or purpose; 

creating metadata for a first module, of one or more modules, that includes any module 
information such as the first module's: binary signature, name, directory path, 
and characteristics; 
inserting the metadata of the first module into the software package; and 
gathering application program interface (API) dependency information for the 

first module, wherein the first module can provide and use at least one API, 

by 

(a) receiving a list of dependent modules for a given process or DLL module 
of the first module; 
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(b) storing, in the metadata of the first module, dependency information for 
the dependent modules in the list, wherein the dependency information 
includes API names and versions that the process or DLL module 
depends on; 

(c) collecting additional dependency information documented in one or more 
additional modules specifications, wherein the additional dependency 
information includes API names and versions that the process or DLL 
module depends on; and 

(d) storing the additional dependency information in the metadata of the first 
module. 

1. The cited art fails to teach or suggest the recited gathering step 
The Office Action admits on pages 5-6 that Broman fails to disclose the recited 
gathering step and steps (a) and (b) of Claim 32. The Office Action then cites paragraphs 8, 
9, and 39-41 of Thurston for allegedly disclosing the recited gathering step and steps (a) and (b) 
(Office Action, page 6). This is incorrect. The only support the Office Action gives is: 
"However, Thurston, more specifically disclosed metadata [0008-0009] to control installations 
and dependency information placed into 'constraints' that must be satisfied [sic?] into a header. 
See FIG. 4. Thurston disclosed 'metadata' held in header files [0039-0041], including version 
number, names of dependent devices, size and checksums, and digital signature." 

Even if Thurston disclosed "dependency information placed into 'constraints'", 
Thurston fails to teach gathering API dependency information for a first module in a 
software package. Thurston lacks any teaching or suggestion of API dependency 
information, much less how such dependency information is gathered. Claim 32 recites that 
API dependency information is gathered by: 

(a) receiving a list of dependent modules for a given process or DLL module; [and] 
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(b) storing, in the metadata of the first module, dependency information for the 
dependent modules in the list, wherein the dependency information includes API 
names and versions that the process or DLL module depends on. 

Thurston fails to teach or suggest anything about APIs. Furthermore, the Office Action fails to 

cite any part of Thurston that describes the claimed "list of dependent modules" and "given 

process or DLL module". 

The Office Action seems to contend that the "first module" of Claim 32 is the 

"firmware update package 108a" of Thurston, because the Office Action identifies the 

"metadata" of Thurston, the firmware update package of Thurston includes metadata, and the 

"metadata" recited in Claim 32 is for the first module. However, in addition to metadata, the 

firmware update package includes a firmware image for installation. The metadata in the 

firmware update package includes: 

(a) a header, which includes a name of a device dependent plug-in module that is 

invoked by a firmware update application to interpret the dynamic constraints 
specified in the header (paragraph 9); and 

(b) dynamic constraints (paragraphs 8 and 9), which may indicate: 

(32) a version of a firmware upgrade in the firmware update package (paragraph 

42), 

(33) a minimum version number of an already installed firmware on a hardware 

device (see FIG. 4 and Claim 5), and 

(34) a version of the firmware update application that is capable of initiating the 

interpretation of dynamic constraints (see FIG. 4 and Claim 5). 
The device dependent plug-in module named in the header portion of the firmware update 
package is specific to a particular hardware device (paragraph 35). But Thurston fails to 
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provide gathering API dependency information for the firmware update package and fails 
to describe a firmware software package that can provide and use at least one API. In 
Thurston, no API dependency information is gathered for the firmware update package and the 
firmware update package does not provide any APIs. 

Nothing in Thurston describes the claimed list of dependent modules that a given 
process or DLL module of the firmware update package (i.e., the alleged first module) is 
dependent on. Indeed, neither the header nor the dynamic constraints portion of the firmware 
update package indicates a list of dependent modules for the recited process or DLL module. 
Even if dependency information were stored in the metadata of a firmware update package, 
Thurston fails to teach or suggest anywhere that such dependency information "includes API 
names and versions that the process or DLL module depends on", as recited in Claim 32. 

2. Broman fails to teach or suggest a "development and build environment 
for packaged software delivery in a distributed network of nodes " 

The Office Action cited col. 4, lines 65-66 and col. 20, lines 52-63 of Broman for 
disclosing "a development and build environment for packaged software delivery in a 
distributed network of nodes." Later, the Office Action on page 5 equates the application 
project 54 of Broman with the recited software package. As the cited portions of Broman 
indicate, Broman describes how a custom application project generator 52 is created in order to 
generate an application project 54. In order to read on Claim 32, the application project 54 
would have to be delivered to nodes in a distributed network. However, col. 20, lines 52-63 
of Broman merely states that "a collection or library of custom application project 
generators. . .can be distributed to users on a computer readable storage medium, or alternatively 
made available for access over a computer network." Thus, Broman teaches that the custom 
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application project generator 52 is made available for access over a network, and not that the 
application project 54 is delivered to nodes in a distributed network. 

3. Broman fails to teach or suggest that a module contains an image for a 
process or a DLL 

The Office Action cites col. 6, lines 27-32 of Broman for disclosing dynamically linked 
libraries. However, Claim 32 recites that "a module contains an image for a process or a 
dynamically linked library (DLL)." The cited portion of Broman merely states: "A linker then 
links the object code files and .RES files together into a. . .("DLL") type program. The custom 
application project generator 52 in the form of a .DLL file contains the compiled code from the 
source files, as well as the dialog resources 68 and the templates 70." From the cited portion of 
Broman, the Office Action appears to contend that the custom application project generator 52 
is the claimed DLL. But on page 5 the Office Action equates the application project 54 with 
the "software package" of Claim 32 that includes a module. Based on the reasoning of the 
Office Action, application project 54 would have to comprise a module that contains an image 
for the custom application project generator 52. Not only does Broman clearly not teach that 
the application project 54 comprises a module that contains an image for the custom application 
project generator 52, such a correlation does not make sense since it is the custom application 
generator 52 that generates the application project 54. 

4. Broman cannot be combined with Thurston 

MPEP § 2143 provides three requirements for a prima facie case of obviousness. First, 
there must be some suggestion or motivation, either in the references themselves or in the 
knowledge generally available to one of ordinary skill in the art, to modify the reference or to 
combine reference teachings. Second, there must be a reasonable expectation of success. 
Finally, the prior art reference (or references when combined) must teach or suggest all the 
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claim limitations. The Office Action asserts no reasonable suggestion or motivation in either 
reference or in the knowledge generally available to one or ordinary skill in the art to modify 
Broman or to combine the teachings of Broman and Thurston. 

The Office Action states that "it would have been obvious. . .to modify Broman' s 
invention to include additional details in the component header such as names, versions, and 
dependency constraints, as disclosed by Thurston, because such information contained in a 
header file as meta data is useful for conveying relevant information when delivering software 
for installation" (page 7). The Office Action then asserts that Thurston contains a motivation: 
"Thurston was motivated (Thurston-[0010]) to provide updates to support new and different 
types of devices in a manner to simplify development and maintenance." Applicants 
respectfully disagree. As stated above, Broman is directed to providing a mechanism for 
creating a custom application project generator that can be used to generate specific 
application programs. Nothing in Broman is related to software package delivery, much less 
software package delivery to nodes in a distributed network, as Claim 32 recites. Therefore, 
it would not have been obvious to one of ordinary skill in the art at the time of the invention to 
combine Broman and Thurston. 

B. INDEPENDENT CLAIMS 37, 44, 51, AND 58 

Independent Claims 37, 44, 51, and 58 are similarly allowable because they include 
some of the same features discussed above with respect Claim 32. 

C. DEPENDENT CLAIMS 

Each of Claims 33-36, and 38-43, and 45-50, 52-57, and 59-62 is dependent upon one 
of independent Claims 32, 37, 44, 51, and 58. By dependency, each of Claims 33-36, and 38- 
43, and 45-50, and 52-57, and 59-62 includes some of the same features discussed above with 
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respect to Claim 32. Therefore, each of Claims 33-36, and 38-43, and 45-50, and 52-57, and 
59-62 is allowable for the same reasons discussed above for Claim 32. 

m. CONCLUSION 

For the reasons set forth above, it is respectfully submitted that all of the pending claims 
are now in condition for allowance. Therefore, the issuance of a formal Notice of Allowance is 
believed next in order, and that action is most earnestly solicited. 

The Examiner is respectfully requested to contact the undersigned by telephone if it is 
believed that such contact would further the examination of the present application. 

Please charge any shortages or credit any overages to Deposit Account No. 50-1302. 



Dated: December 26, 2006 

2055 Gateway Place, Suite 550 
San Jose, CA95110 
(408)414-1080 
Facsimile: (408) 414-1076 



Respectfully submitted, 



HICKMAN PALERMO TRUONG & BECKER LLP 




Daniel D. Ledesma 
Reg. No. 57,181 
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